Subject: Timestamps in SNA Related MIBs

From: "David D. Chen ((919)-254-6182 8-444)" <[email-masked]>
Date: Fri, 10 Nov 95 11:47:01 EST

Ref:  Your note of Sat, 4 Nov 1995 00:35:29 -0500 (attached)

I posted the attached note to dlsw mailing list.  Since
the same subject is discussed in APPC/APPN mibs, Bob Moore
suggested that I should post here also.  David Chen

......................................................................

I don't appreciate the attached note which are full
of inaccurate facts, unbalanced analyses, and making
unnecessary labeling/judgement.  It may happen in other
mailing list, but I seldom (if ever) see this in the
dlsw mib mailing list.  Lets keep the record straight.
IBM is a multiprotocol vendor with many brilliant
people who understand customers needs and deliver
the best solutions.  We support standard activities,
and give our best input.  Each of us participate the
IETF activities just like everyone else, and find the
best common solutions to meet the market's needs.

Lets focus on the technical issues on the subject.
Who can't say they don't like to have the same clock
for everything.  Thus the events can be order easily.
However, the timestamps could be easily mis-stamped
due to the drifting-apart clocks, when the process is
scheduled, clock changes, ...   I don't think the
goal is just try to make nice on paper (MIB definition)
and up to implementors to do their best they can.

In my mind, whether supporting sysUpTime is not
the issue driving to the xxxxTimeStamp solution.
Key issues are:
(1) Distributed environment.
    That is, the agent and dlsw instrumentation runs
    in different processors/adaptor with it own clock.
    Will the clocks drift apart?
    Should agent assign the timeStamp, or each adaptors
    assign?

(2) Agent and subagent relation
    There are commercial available agents don't
    have the interface to distribute the sysUpTime.

(3) Even they do,
    what will happen if the agent code got recycled, while
    other part of the box (e.g., dlsw) continue running?
    - sysUpTime needs to be reset?  since there are
      counters that depend on sysUpTime to show the counters
      are discontinued?  How about those TimeStamps in
      the instrumentation, should they be changed or not?
    - Or should agent consult all parts of the system and
      try to derive the sysUpTime?  or there is a place in
      the box store the time?

These are not new problems.  I guess either those products
just don't have this kind distributed system, or agent-
instrumentation relation, or dynamic unload/reload, or
they just do their best?  (I like to hear how you solve those
problem.)  The dlswMIB v7 TimeStamp definition just
wants to reduce problems for these situations while gives
user a technique to correlate back to sysUpTime.

I will comment Bob Moore's proposal on APPN MIB later.

David Chen

>---------------------------- Note follows ------------------------------
>Received: from www.raleigh.ibm.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP;
>   Sat, 04 Nov 95 00:35:24 EST
>Received: from localhost.ncren.net by www.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03)
>          id AA28928; Sat, 4 Nov 1995 00:35:29 -0500
>Date: Sat, 4 Nov 1995 00:35:29 -0500
>Message-Id:  <"7476.Sat.Nov..4.00:29:01.1995"@bnr.ca>.
>Errors-To: [email-masked]
>Reply-To: [email-masked]
>Originator: [email-masked]
>Sender: [email-masked]
>Precedence: bulk
>From: "jim (j.) cobban" <[email-masked]>
>To: [email-masked]
>Subject: Timestamps in SNA Related MIBs
>X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
>X-Comment:  MIB discussions
>
>At the APPN MIB session at the recent AIW there was some heated discussion
>about time stamps.  I do not know where all of the relevant mailing lists for
>these discussions are.  In particular I cannot find a mailing list for the
>APPC MIB.
>
>On the one side there were the multiprotocol vendors.  For them SNA, APPN, HPR,
>DLSw, and APPC are just a few more protocols to add to already crowded boxes.
>They want to treat these protocols as much like the other protocols as
>possible.  More particularly they want all agents to report the time stamps
>for events in the same way so that a sequence of events can be correlated.
>For example if there is a failure on a V.35 port and a failure of an SNA
>route which happens to pass through that port, then it is considered HIGHLY
>important that those two events have time stamps which are directly
>comparable.  Note that the SNA NAU MIB and SNA DLC MIBs use sysUpTime
>exclusively.
>
>On the other side there are implementors of SNA only boxes which want to use
>SNMP only because it provides a convenient common way of consistently
>describing all equivalent components.  Several of these have vehemently
>insisted that it is IMPOSSIBLE for them to report sysUpTime.
>
>The only real value of SNMP is in its ability to represent all of the
>management information about a network within the MIB.  For any individual
>component a proprietary management interface will always be superior because
>there is no need to compromise on the representation of the structure of the
>information.  SNMP is only of value, therefore, when you can correlate
>information presented by one component with information presented by another.
>Using independent clocks for different components makes this correlation
>difficult or impossible, and therefore raises the question "Why are you doing
>SNMP management at all?"  The fact that the set of MIBs for which this
>special treatment is being demanded are all IBM initiated and SNA related
>creates special political problems.
>
>It is difficult for many of us to accept the objections to implementing
>sysUpTime.  In particular implementation of sysUpTime is MANDATORY for all
>systems according to RFC1213.  It is therefore difficult to understand how
>these vendors could claim to be implementing SNMP when they do not provide
>this object.  I can appreciate that there are situations in which it is very
>difficult to provide sysUpTime.  For example Nortel has one platform that
>only has a time of day clock and does not record in the module when it was
>started.  It also does not have an IP stack, or a sockets interface, or any
>of the other myriad features which are assumed in SNMP.  That did not stop
>Nortel from presenting sysUpTime out of our SNMP agent.  Even if the local
>implementation of any of these SNA protocol stacks does not wish to
>interrogate sysUpTime every time a state change occurs in their service, all
>that is necessary is for the service specific management agent to save the
>value of sysUpTime at the time that the service started, and to add that
>value to all of its internal timestamps at the point where they are reported
>up to the management system.
>
>However these implementors are presumeably genuine in their belief that it
>is IMPOSSIBLE for them to present the sysUpTime values for events.  So
>we have a conflict.
>
>Now the APPC MIB has been proposed in draft-ietf-snanau-appcmib-04.txt to use
>a protocol stack specific timer appcUpTime.  The MIB proposes that the
>management station retrieve sysUpTime and appcUpTime and calculate an offset
>to correct all of the time stamps which it retrieves from the MIB.  With this
>precedent it is now proposed to use the same design for the APPN MIB and the
>DLSw MIB.  The claim was made that "the IETF did not object to a private time
>stamp".  However the APPC MIB is only a draft.  However the full set of SNA
>related MIBs ideally should be enshrined as extensions of the standard
>MIB-II, and the conditions of approval as an IETF standard are much tighter.
>
>So on the one side we have the multiprotocol vendors and the architectural
>purists who insist that all events should be time stamped with sysUpTime, and
>on the other hand we have IBM, standing bravely alone and depending upon the
>AIW's tradition of consensus to protect its unique right to special
>treatment.
>
>I do not believe that IBM has proved its case for special treatment, and that
>therefore the AIW should not approve any of these MIBs for presentation to
>the IETF until this case is established.  However in the spirit of consensus
>I have proposed a compromise.  This requires changing slightly the definition
>of xxxxUpTime in each of these proposed MIBs, and adding an additional object
>in each MIB after xxxxUpTime.  The changes look like:
>
>-- *********************************************************************
>-- Textual Convention
>-- ---------------------------------------------------------------------
> xxxxTimeStamp ::= TEXTUAL-CONVENTION
>      STATUS current
>      DESCRIPTION
>|         "The value of xxxxUpTime when an event occurred.  Normally all
>|	  events in this MIB are time stamped using sysUpTime.  However
>|         there are implementations in which the value of sysUpTime is
>|         not available to the xxxx management agent.  In this case the
>|         value of xxxxUpTime is relative to the time when the xxxx
>|         component came up.  A Management Station can relate
>|         these time stamps to sysUpTime by retrieving sysUpTime and
>|         xxxxUpTime, and calculating the difference between them."
>      SYNTAX  TimeTicks
>..
>
> xxxxUpTime  OBJECT-TYPE
>     SYNTAX     TimeTicks
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>|       "This is equal to the value of sysUpTime if sysUpTime
>|        is available to the xxxx portion of the system.  If the
>|        value of sysUpTime is not available then it is the
>|        time (in hundredths of a second) since the xxxx portion
>|        of the system was last re-initialized."
>     ::= { xxxx n }
>
>|xxxxStartTime  OBJECT-TYPE
>|    SYNTAX     TimeTicks
>|    MAX-ACCESS read-only
>|    STATUS     current
>|    DESCRIPTION
>|       "The value of xxxxUpTime at which the xxxx portion of
>|        of the system was last re-initialized.  If the
>|        value of sysUpTime is not available to the xxxx
>|        portion of the system, then this value is set
>|        to zero."
>|    ::= { xxxx n+1 }
>
>If an implementation wishes to present sysUpTime for all events then it is
>freed by this proposal to do so.  If the implementation cannot report
>sysUpTime values then it simply sets xxxxStartTime to zero and reports the
>protocol specific relative times.  The wording is chosen to make it clear
>that reporting sysUpTime values is preferred and an alternate clock is to be
>used only if sysUpTime is not available.
>
>This is not a totally satisfactory solution because a management station
>cannot tell, except by examining the value of xxxxStartTime, or comparing the
>values of xxxxUpTime and sysUpTime, which of the two techniques the
>implementor has chosen.
>
>There are some stack specific notes.  The description of dlswNodeUpTime in
>the DLSw MIB implies an implementation in which the entire DLSw service
>evaporates whenever dlswState goes to inactive.  A more typical design is for
>at least the SNMP agent to continue to exist even if the service which it
>reports on behalf of is not currently running.  Therefore the description of
>dlswNodeUpTime is proposed to be amended to permit the alternative
>implementation:
>
> dlswNodeUpTime  OBJECT-TYPE
>     SYNTAX     TimeTicks
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>|       "If sysUpTime is available to the DLSw management
>|        agent then this is equal to the value of sysUpTime.
>|	 However if the agent does not have access to sysUpTime
>|	 then this is the time (in hundredths of a second)
>	 since the DLSw portion of the system was last
>|	 re-initialized.  That is, if dlswNodeStatus is active,
>|        the time the dlswNodeStatus entered the active state.
>|        It may be set to, and remain, zero if dlswNodeStatus is
>|        inactive."
>     ::= { dlswNode 6 }
>
>Note that the name of the state object is incorrect in the text in draft 7 of
>the DLSw MIB.

---

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 14 Nov 1995 11:33:00 -0500

In message "Timestamps in SNA Related MIBs", 

>unnecessary labeling/judgement.  It may happen in other
...

Please appreciate the state of mind I was in at the time I wrote that
note.  A bunch of bigotted a**holes had just tried, and nearly succeeded, in
tearing my homeland apart because they demanded special treatment.  Then I
have IBM demanding special treatment for their products, and I snapped.
My anger and frustration were not really directed at you, and you should not
have to suffer for it.
...

>the issue driving to the xxxxTimeStamp solution.

These are valid concerns, but there is nothing in them which is unique to
SNA.  What this group needs to establish is why SNA should use a private
timestamp, when nobody else does.

We follow certain conventions in all communications which are intended to
avoid confusion.  For example in these mailing lists it is a convention that
all communications should be in English, regardless of the mother tongue of
the originator.  More related to the issue at hand is the convention that all
dates are expressed relative to the western european christian calendar.
Would it not be confusing if someone sent a note and chose to date it 21
Heshvan 5756 AM, or 20 Jumada II 1416 AH, or even 12.19.2.11.11 8 Chuen
19 Zac ?  If a reader is trying to determine the sequence in which a set of
memos are sent, this would surely frustrate them.